Kineticium

Kineticium is a first-person movement shooter where the faster you go, the more damage you deal and the less damage you take. I made it for my final year project in college in about 4 months in Unity, with my main focus on the mechanics rather than making it look pretty. I did add some minor artistic aspects to it, such as the cartoon-like outline on the guns and enemies, as well as bullet trails and bullet holes in walls.

One of the biggest struggles I had in this project was definitely level design. I did not enjoy doing level design, and thus did not have experience doing it. This became a significant issue when I realised not only did I have to make the maps, I had to design them in such a way to encourage the players to utilise most, if not all, the game's mechanics. Looking back at this project, I'm still not entirely satisfied with it as I think all the levels except the tutorial level don't give the player much freedom, whilst encouraging engagement with the mechanics.

From a technical standpoint, I'm still quite happy with what I did in this project, even if there are a few nitpicks I would change, such as adding a bit more to the enemies' AI, and how the weapon damage scaling worked. From a game design perspective, I feel that with everything I learnt up until now, I'd make quite a few changes, such as simple things like Having a way to keep track of when you can next fire a shot, and giving the player more or clearer feedback to their actions, whether that be hitting an enemy or building up a lot of speed.

A Keen Eye

A keen eye is an isometric/top-down puzzle game where you have to find the odd object out in a sea of them, whilst having intentionally limited controls. I made this in 9 weeks during one of the last modules in my 1st year at University, where my main focus was trying to keep the scope as low as I could since this was my first time using Unreal's Blueprints without any assistance.

One of the biggest struggles I had was with the green outline for showing the player what object you are currently looking at, where, if you looked at two objects in quick succession, it would highlight both objects rather than the latest one. This stumped me for quite a while until I finally resolved it by keeping track of what the last object you looked at was, and checking every 0.25ish seconds if the object you're looking at is the same, and if it isn't, disable the outline on the last object so only the current object has it.

From a technical standpoint, I do feel the game is really basic, and didn't really push me outside any real comfort zones, but it still felt well-scoped and reached where it needed to be for the deadline despite the hiccups. From a game design perspective, I feel like there isn't much to expand upon in terms of gameplay, my choice for such simple and limiting controls was a double-edged sword, where it meant that it was relatively easy to figure out the controls, but where it goes beyond that isn't clear. It also doesn't give the player much freedom as all they can do is look around and spin a level, there isn't really anything else to it. My biggest takeaway is that any mechanics I make in the future need to find the balance between easy to pick up, but also has some depth to it for those wanting to experiment or take things a step up.

Arena Movement Tool

The Arena Movement Tool was a tool I made to assist with creating arena-based movement for bosses, whilst also creating a camera tracking and orbiting system in the process, without realising. I made this in 9 weeks for my Tools Development Module in my 2nd year of University, where I gave myself the challenge of doing everything in C++, with the only semblance of Blueprint usage being the component itself.

The biggest struggle I had for this project was the main orbit behaviour, as I tried looking into physics and circular motion to make it behave like the orbit of a planet or satellite, despite the fact that I had no experience with A-Level physics. Instead, I pivoted to making it move in 360 intervals, mimicking the orbiting behaviour whilst not needing any of that advanced physics.

From a technical standpoint, it is a very simple tool. I once again tried to keep the scope low and not do anything too complicated to reach completion in that 9-week timeframe. When I reached the end and started bug testing it, I was pleasantly surprised to find uses for the tool I had not realised before, such as easy object tracking for the camera to use. I also struggled to find any bugs when doing the testing, except for null ptrs, which were easily fixed with a check for if the object assigned was null, and only allowing the behaviour to work if it wasn't.